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SUMMARY 


The  Integrated  Communication,  Navigation,  and  Identification  Avionics 
(ICNIA)  architecture  is  being  designed  to  replace  several  discrete  avionics 
components  with  an  integrated,  modular  system.  The  goals  of  the  project 
include  improved  system  reliability  and  decreased  size  and  weight.  In  order 
to  meet  these  objectives,  the  ICNIA  technology  must  allocate  available 
resources  in  order  to  respond  to  changes  in  the  mission  environment  or  to 
compensate  for  the  loss  of  system  components.  Thus,  the  reliability  of  ICNIA 
depends  on  both  hardware  design  and  on  the  efficiency  of  the  resource 
allocation  technique. 

This  report  describes  the  ICNIA  resource  allocation  problem  and  presents 
the  mathematics  that  can  be  used  to  approach  a  solution.  In  particular, 
mathematical  programming  methods,  sequential  allocation  algorithms,  and 
combinational  algorithms  are  each  evaluated  for  their  ability  to  solve  this 
problem.  A  preliminary  analysis  of  these  techniques  was  completed  by  defining 
several  measures  of  performance.  The  results  of  this  analysis  are  given, 
along  with  several  recommendations  for  improving  the  design  of  an  ICNIA 
resource  allocation  technique. 


PREFACE 


This  report  documents  research  into  the 
behavior  of  resource  allocation  algorithms  for  Inte¬ 
grated  Communication,  Navigation  and  Identification 
Avionics  (ICNIA)  and  methods  for  evaluation  of  the 
performance  of  such  algorithms.  These  findings  are 
results  of  the  Fault  Tolerance  Analysis  task  of  the 
Impact  Analysis  of  ICNIA,  Air  Force  Contract  No.  F33615 
82-C-0002.  This  work  is  jointly  supported  by  the 
Air  Force  Human  Resources  Laboratory  and  the  Air 
Force  Wright  Aeronautical  Laboratories.  The  guidance 
and  support  of  Mr.  James  C.  McManus  and  Lt  Lee  H. 
Dayton  are  greatly  appreciated. 
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1 .  INTRODUCTION 


1 . 1  BACKGROUND 

The  Integrated  Communication,  Navigation,  and 
Identification  Avionics  (ICNIA)  system  is  being  designed 
to  replace  a  number  of  discrete  avionics  components  with 
an  integrated,  modular  system.  This  project  has  several 
design  goals,  including  decreased  system  size  and  weight, 
improved  reliability,  and  decreased  logistical  support 
requirements.  The  approach  being  taken  is  that  of  active 
redundancy;  that  is,  available  system  resources  will  be 
reallocated  to  perform  particular  tasks  in  response  to 
changes  in  mission  requirements  or  to  compensate  for  the 
loss  of  system  components.  As  such,  the  reliability  of 
ICNIA  in  providing  designated  functions  depends  on  both 
the  hardware  design  and  the  efficiency  of  the  resource 
allocation  technique. 

New  methodologies  have  been  required  to  project 
the  probable  performance  of  alternative  ICNIA  designs. 

One  such  tool,  the  Missionized  Reliability  Model  (MIREM) 
(Veatch,  Calvo ,  Myers,  and  McManus,  1985),  is  used  to  eval¬ 
uate  several  measures  of  the  reliability  of  ICNIA  hardware 
designs  in  providing  designated  functions.  MIREM  is  de¬ 
signed  to  be  independent  of  ICNIA  resource  allocation  tech¬ 
niques  and  allows  the  best  performance  achievable  with  a 
particular  hardware  design  to  be  determined.  The  objectives 
of  the  current  effort  are  to  complement  MIREM  by  defining 
measures  of  performance  for  resource  allocation  techniques, 
and  to  provide  a  preliminary  assessment  of  the  strengths 
and  weaknesses  of  several  such  alternative  techniques. 


1 . 2  APPROACH 

The  objective  of  the  resource  allocation  technique 
is  viewed  here  as  maximization  of  the  expected  usefulness 
to  the  operator  of  the  ICNIA- supported  functions.  The 
approach  taken  in  evaluating  the  resource  allocation  prob¬ 
lem  is  to  employ  the  framework  of  optimal  control  theory. 

In  order  to  make  use  of  the  substantial  body  of  work  on 
optimal  control  theory,  certain  notions  such  as  "useful¬ 
ness"  are  first  made  concrete.  Reasonable  simplifications 
are  made  in  order  to  improve  the  analytical  tractability 
of  the  problem. 


Th,-  overall  optimization  framework  is  then  used 
to  tonnuidt.-  measures  of  allocation  performance  for  general 
subop t  i. mu i  allocation  techniques.  Since  these  proposed 
measures  nre  derived  directly  from  the  previously  stated 
optimization  problem,  they  capture  important  features  of 
allocation  performance.  In  addition,  several  measures  of 
the  comput at iona 1  burden  of  allocation  techniques  are  pro¬ 
posed.  In  this  way,  an  explicit  evaluation  of  the  alloca¬ 
tion  benefits  and  computational  costs  of  any  allocation 
technique  can  be  made.  Such  evaluations  can  be  used  in 
making  trade-off  analyses  during  the  design  cycle  of  1CNIA 
resource  allocation  techniques. 

Because  no  well-defined  allocation  techniques 
have  yet  been  developed  by  ICNIA  contractors  for  evalua¬ 
tion.  this  report  provides  preliminary  assessments  of  the 
performance  of  several  generic  resource  allocation  tech¬ 
niques.  Each  of  the  techniques  --  mathematical  programming 
methods,  sequential  allocation  algorithms,  and  combinatorial 
algorithms  --  is  evaluated  for  its  ability  to  provide  a 
good-quality  solution  to  the  ICNIA  resource  allocation 
probl em . 


1.3  ORGANIZATION  OF  REPORT 

This  report  is  organized  in  five  chapters.  The 
introductory  chapter  establishes  the  scope  of  the  effort 
and  the  approach  taken.  Chapter  2  formulates  the  optimal 
control  theory  framework  for  the  ICNIA  resource  allocation 
problem  and  includes  a  simple  example  of  these  concepts 
(Section  2.3.2).  Chapter  3  addresses  the  preliminary  assess¬ 
ment  of  alternative  allocation  techniques,  and  several 
measures  of  allocation  performance  are  proposed  in  Chap¬ 
ter  4.  A  summary  and  recommendations  are  presented  in 
Chapter  5. 


OPTIMAL  ALLOCATION  FRAMEWORK 


3-!  Ai.cCr  ;  i  HMS  ANu  IMPLEMENTATIONS 

t  f.  tri  i  ques  to  be  applied  in  allocating  avail- 
ati-  i-dwui.  s  ;  accomplish  desired  functions  can  be  divided 
>  on,  •  pt a  a i  1 v  into  two  phases.  The  first  phase  is  algorithmic 

s»»:l  ut  i  •  ui  ;  -!i"  st-vorui  phase  is  implementation. 


The  algorithmic  solution  phase  describes  how  ill.- 
cation  decisions  are  made.  An  allocation  algorithm  is 
defined  in  terms  of  its  inputs,  calculations,  and  outputs. 
Inputs  to  such  an  algorithm  include  diagnostic  inlonnation 
about  the  state  of  system  health  and  operator  interactions 
Outputs  include  statements  about  how  functions  will  be 
supported  by  the  system  resources.  The  calculations  de¬ 
scribe  the  way  in  which  the  outputs  are  derived  from  the 
inputs . 

The  implementation  phase  describes  how  a  partic¬ 
ular  algorithm  will  be  performed  in  a  particular  hardware 
system.  Implementation  includes  the  software  and  hardware 
partitioning  of  the  algorithm.  In  general,  although  there 
may  be  many  possible  implementations  of  a  given  algorithm 
in  a  given  hardware  system,  they  will  all  have  identical 
performance  from  the  standpoint  of  providing  ICNIA  func¬ 
tions.  Proper  partitioning  is  needed  to  satisfy  the  eoinpu 
tational  capabilities  of  the  system.  Consequent lv ,  the 
allocation  algorithm  must  be  designed  before  an  implement  a 
tion  can  be  selected. 

The  allocation  algorithm  must  be  optimized  within 
the  framework  imposed  by  the  ICNIA  system  constraints. 
These  constraints  can  be  stated  as  follows.  The  algorithm 
must  allocate  limited  system  resources  to  perform  multiple 
functions.  It  must  provide  for  dynamic  reconfiguration  to 
support  operator-defined  changes  in  preferred  functions 
and  to  allow  graceful  degradation  of  overall  system  func¬ 
tionality  as  resources  fail.  The  timing  of  resource  fail¬ 
ure  is  not  known,  although  the  statistical  reliability  ot 
resources  is  known.  This  problem  can  best  be  formulated 
in  terms  of  dynamic  stochastic  optimization. 

In  Section  2.2,  the  ICNIA  resource  allocation 
problem  is  put  in  the  form  of  dynamic  stochastic  optimiza¬ 
tion,  and  some  of  the  characteristics  of  an  optima!  solu¬ 
tion  of  this  problem  are  noted.  Under  certain  con  lit  ions, 
this  problem  can  be  simplified  considerably.  1 :.  i  s  results 
in  a  static  deterministic  optimization  probl>-m.  is  shown 
in  Section  2.3. 


2.2  DYNAMIC  OPTIMIZATION 

The  fundamental  concept  in  using  dynamic  opiimiza 
tion  techniques  in  allocating  ICNIA  resources  is  il  lust  tat 
in  Figure  1.  That  concept  is  that  the  "us“  fu  1  tiew>-.  ~  >t 
an  ICNIA  resource  allocation  depends  on  the  priori' \  it  ‘  n 
to  the  functions  implemented.  Ordering  the  nrooii  ■ 
all  possible  sets  of  functions  is  the  respotis  i  bl  .  tv  ' 
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Figure  1 ■  Dynamic  Optimization. 


the  pilot  and/or  mission  planner;  in  this  way,  the  alloca¬ 
tion  algorithm  is  Cold  what  is  desired.  In  turn,  the  allo¬ 
cation  algorithm  must  use  both  the  function  set  priorities 
and  information  about  available  resources  to  select  the 
best  allocation  available. 

2.2.1  Priority  Sets 

It.  is  important  to  note  that  sets  of  functions, 
rather  thin  individual  functions,  must  be  arranged  in  order 
of  priority.  This  approach  is  more  general,  as  it  includes 
the  ordering  of  individual  functions  as  a  special  case. 

By  ordering  sets  of  functions,  it  is  possible  to  allow  the 

r  i  on  of  two  functions,  each  individually  slightly 
/'-■  important,  rather  than  one  function  which  is  individ- 
uoi.v  >l;ghtly  more  important.  For  example,  the  "limp 
home"  Junctions  may  include  any  one  communication  system 
and  any  one  navigation  system.  Ordering  functions  individ¬ 
ually  might  result  in  the  selection  of  two  communication 
systems  or  two  navigation  systems,  which  would  be  less 
desirable. 


b 


2.2.2  State  of  System  Health 

It  has  been  pointed  out  (Veatch  et  al ,  1985) 
that  the  condition  of  the  system  hardware  at  any  time  can 
be  specified  by  the  number  of  healthy  units  in  each  pool 
of  resources.  ICNIA  will  contain  facilities  for  Built-In 
Test  (BIT),  which  will  allow  the  allocation  algorithm  to 
be  informed  as  to  the  current  state  of  system  health.  It 
should  be  noted,  however,  that  there  may  possibly  be  device 
failures  which  are  not  detected  by  BIT.  Thus,  the  state 
of  system  health  may  never  be  known  perfectly. 

2.2.3  Resource  Strings 

There  are  generally  a  limited  number  of  ways  in 
which  any  ICNIA  function  can  be  accomplished.  Each  such 
way  can  be  specified  in  terms  of  how  many  units  are  re¬ 
quired  from  each  pool  of  system  hardware.  Such  a  specifica¬ 
tion  is  called  a  resource  string  in  this  work.  If  desired, 
all  of  the  possible  resource  strings  for  each  function 
could  be  formed  into  a  table  of  resource  requirements  of 
the  form  r(i,j,k),  where 


i  is  the  function  number 

j  is  the  resource  string  number  (for  the 
ith  function) 

k  is  the  pool  number  (for  the  j th  resource 
string  for  the  ith  function) 

r(i,j,k)  is  the  number  of  units  required  in  pool  k 
to  accomplish  function  i  using  resource 
string  j . 


Note  that  resource  requirements  can  be  fractional ,  repre¬ 
senting  time-shared  resources.  By  specifying  pools  rather 
than  individual  devices,  the  allocation  problem  is  held  to 
a  practical  dimension.  Selection  of  particular  devices 
within  a  pool  can  be  handled  by  a  very  simple  local  sched¬ 
uling  algorithm. 

2.2.9  Control  Vector 

An  allocation  decision  must  specify  not  only  which 
functions  are  to  be  performed  but  also  which  resource  strings 
or  paths  will  be  used  to  perform  them.  This  is  because  not 
all  resources  of  one  type  can  be  connected  to  all  resources 
of  another  type;  only  certain  interconnections  are  possible. 
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If  all  possible  resource  strings  for  each  function  are 
listed,  then  the  allocation  decision  consists  of  selecting 
which  particular  string  is  to  be  used  for  each  function. 
The  list  of  all  of  these  resource  string  selections,  taken 
together,  constitutes  the  control  vector. 

2.2.5  Form  of  Objective  Function 

All  of  the  above  components  of  the  dynamic  stochas 
tic  optimization  problem  can  now  be  assembled.  An  optimal 
allocation  algorithm  generates  a  function,  h,  that  maps 
all  available  information  about  system  health,  I,  into  a 
control  vector,  u: 


u  =  h(  I  ) 

in  order  to  maximize  the  objective  function 

r  t 

p(  f  (x(  t )  ,  u(  t )  )  ,  t  )dt  j" 

J 

where 

f  denotes  the  system  functions  actually 
operational  given  a  control  vector  u 
and  a  system  health  state  x 

p  denotes  the  priority  of  this  set  of 
f unc  t ions 

T  is  the  time  between  maintenance  actions 

E  denotes  the  statistical  expectation 
due  to  uncertainties  about  x. 


J(T)  =  E 


/ 


(  1) 


(2) 


This  objective  function  reflects  all  of  the  essen¬ 
tial  char  act  «*rist  ies  of  the  ICN1A  allocation  problem.  It. 
is  import  int  to  note  that  the  allocation  algorithm  may 
need  to  take  into  account  explicitly  the  probabilistic 
nature  . ,  t  ->vst>-m  health.  It  is  also  important  to  note 
that  the  algorithm  must  be  concerned  with  the  performance 
ot  t he  svstem  over  the  whole  time  between  maintenance  ac¬ 
tions.  This  i  particularly  significant  if  I CN I  A- equipped 
aircraft  at--  -expected  to  operate  from  austere  bases  ,  where 
replacement  mopuA-s  mav  not  be  available  after  each  mission 


Optimization  problems  of  this  general  type  have 
been  addressed  in  the  literature  (Chizeck,  1981;  Griffiths, 
1983;  Rishel,  1978;  White,  1974).  Some  of  the  characteris¬ 
tics  of  the  solutions  to  these  problems  should  be  pointed 
out . 

First,  reconfiguration  time  is  implicitly  con¬ 
sidered  in  the  optimization,  since  the  whole  time  interval 
is  of  interest.  For  time-critical  functions  such  as 
Identif ication-Friend-or-Foe  (IFF)  Transpond,  this  may 
result  in  the  simultaneous  operation  of  a  function  in  two 
or  more  independent  resource  strings  in  order  to  provide 
an  instantaneous  backup.  Furthermore,  similar  considera¬ 
tions  would  apply  to  the  time  required  to  turn  off  and 
reinitialize  system  resources. 

Second,  an  optimal  algorithm  can  make  use  of  all 
information  about  the  state  of  health  of  the  system.  This 
may  include  BIT,  techniques  for  soft  failure  detection, 
and  the  monitoring  of  functional  outputs.  These  sources 
of  information  are  combined  using  probability  models  both 
for  resource  failures  and  for  the  effectiveness  of  the 
fault  detection  methods  employed. 

Third,  the  allocation  algorithm  may  actually  select 
a  control  vector  partly  in  order  to  learn  more  about  the 
state  of  system  health.  This  "dual  control"  aspect  (Feldbaum, 
1960/1961;  Griffiths,  1983)  results  from  an  implicit  trade¬ 
off  betw;en  the  cost  of  reduced  functionality  now  versus 
improved  knowledge  of  system  health  and  improved  functional¬ 
ity  in  the  future. 

Fourth,  due  to  the  probabilistic  and  dual-control 
aspects  of  this  problem,  optimal  solutions  are  generally 
very  difficult  to  obtain. 


2.3  STATIC  OPTIMIZATION 


Problem  Simplification 


The  difficulty  in  solving  the  dynamic  stochastic 
problem  arises  from  two  factors.  First  is  the  implicit 
recognition  of  the  importance  of  speed  of  reconfiguration; 
second  is  the  imperfect  knowledge  of  system  health.  Con¬ 
sequently,  the  problem  can  be  greatly  simplified  if  two 
approximations  can  be  made  to  hold.  If  there  is  an  insigni¬ 
ficant  penalty  for  downtime  while  the  system  reconfigures 
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and  if  there  is  an  insigni f icant  penalty  for  decoupling 
resource  allocation  and  failure  detection  (i.e.,  only  cur¬ 
rently  available  resource  health  information  is  used), 
then  the  dynamic  stochastic  optimization  problem  resolves 
into  a  sequence  of  static  problems. 

To  simplify  the  discussion,  it  will  also  be  assumed 
that  there  is  perfect  knowledge  of  system  health  (100%  BIT 
effectiveness),  although  static  optimization  can  also  be 
applied  to  the  case  of  imperfect  BIT.  For  the  static  case, 
the  reconfiguration  algorithm  is  solved  each  time  there  is 
a  change  in  function  set  priorities  or  in  the  state  of 
system  health.  A  control  vector  u  is  selected  in  order  to 
maximize 


J  =  P( f ( x ( t )  ,  u(t)  )  ,t)  (3) 


where  all  terms  are  defined  as  before.  Note  that  this 
optimization  problem  itself  is  not  concerned  with  antici¬ 
pating  future  effects,  nor  does  it  have  a  random  element. 
This  is  because  the  temporal  and  random  effects  enter  via 
the  changes  in  priorities  and  in  system  health  state,  which 
signal  when  to  perform  the  static  optimization. 

For  the  static  problem,  it  can  be  seen  that  the 
control  vector  selected  must  not  require  more  resources 
from  any  pool  than  are  available.  That  is,  referring  to 
Sect  ion  2.2.3, 


k)  <_  for  all  k 


(4) 


where  u  ^  is  the  resource  string  selected  for  the  i  func¬ 
tion,  and  is  the  number  of  healthy  units  in  the  k1^1  pool. 

This  condition  forms  a  set  of  constraints  for  the  static 
optimization  problem. 

It  should  be  noted  that  good  system  design  can 
force  the  approximation  conditions  to  hold.  The  require¬ 
ment  that  ICNIA  be  able  to  recon  figure  in  10  seconds  is  a 
way  to  guarantee  that  there  is  an  insignificant  penalty 
for  system  downtime.  Similarly,  if  all  known  device  failure 
modes  are  detectable  through  BIT,  the  penalty  for  decou¬ 
pling  resource  allocation  and  failure  detection  is  proba¬ 
bly  insignificant. 
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2.3.2  Example 


In  this  subsection,  a  simple  example  of  resource 
allocation  will  be  presented  to  point  out  various  aspects 
of  function  set  priorities,  state  of  system  health,  table 
of  resource  strings,  and  control  vector.  In  Chapter  3, 
this  example  will  be  used  to  examine  some  of  the  strengths 
and  weaknesses  of  alternative  allocation  algorithms. 

In  the  example  depicted  in  Table  1,  there  are 
three  functions:  FI,  F2 ,  and  F3.  Thus,  there  are  eight 
function  sets  to  be  ranked  by  relative  priority.  One  such 
ranking  is  presented  here.  Different  priority  rankings 
can  be  generated  for  different  mission  phases,  and  rankings 
can  be  modified  by  the  pilot.  (It  is  not  yet  known  how 
the  pilot  interaction  will  be  managed  in  ICNIA. )  Note 
that  it  is  sometimes  preferable  to  have  one  function  (Pri¬ 
ority  4)  rather  than  two  functions  (Priority  5).  Note 
also  that  no  single  function  has  absolute  priority  in  this 
example . 

There  are  four  pools  of  resources  in  this  example. 
The  state  of  system  health  depicted  in  Figure  2  can  be 
represented  as  x  =  (1,  2,  1,  2),  summarizing  the  number  of 
healthy  units  in  each  pool  (PI,  P2 ,  P3 ,  P4 ) .  If  one  unit 
were  to  fail  in  pool  P4 ,  the  system  state  would  be  repre¬ 
sented  as  x  =  ( 1 ,  2  ,  1 ,  1 )  . 


Table  1.  Static  Optimization  Example 
Function  Set  Priorities 


Function 

Set  Priorities 

Func  t ions 

1 

FI  , 

F2  ,  F3 

2 

FI, 

F2 

3 

F2, 

F3 

4 

F2 

5 

FI  , 

F3 

6 

FI 

7 

F3 

8 

None 

9 
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Figure  2.  Example:  System  State  (Full-Up). 


The  resource  strings  representing  all  possible 
ways  of  performing  each  of  the  three  functions  in  the  given 
system  are  presented  in  Table  2.  Each  of  the  functions 
can  be  performed  in  either  of  the  two  chains  in  the  system. 
In  addition,  F3  can  be  performed  cooperatively  in  both 
chains,  although  this  results  in  increased  total  resource 
requirements  due  to  increased  overhead  (compare  resource 
strings  1  and  2  of  function  F3  with  string  3). 


Table  2.  Example:  Resource  Strings 


F unc  t ion 

Resource 

String 

Designation 

Resource  Utilization 

Pool 

PI 

Pool  ! 
P2  1 

! 

Poo  1 
P3 

Poo  1 
Pd 

FI 

1 

2 

l 

1 

0 

0 

1 

0 

1 

V  1 

1 

0 . 5 

i 

0 

0 

F2 

2 

0 

0 

0.5 

1 

1 

0 . 5 

1 

0 

0 

F3 

2 

0 

0 

0.5 

1 

3 

■  0.25 

J _ 

0.7  1 

_ L 

0 . 25 

0.7 

It  can  be  seen  that  two  different  control  vectors 
can  exercise  all  three  functions  when  uLl  system  resources 
are  healthy.  These  two  control  vectors  are  u  =  (1,  2,  2) 
ind  u  -  ( 2 ,  1  .  1  )  .  If  u  -  (  1  .  2  ,  2 )  is  Selected,  then: 


1.  FI  is  performed  via  resource  string  1 
(pools  Pi  and  P2) 

2.  F2  is  performed  via  resource  string  2 
(pools  P3  and  P4) 

3.  F3  is  performed  via  resource  string  2 
( pools  P3  and  P4 ) . 


If  u  =  (2,  1,  1)  is  selected,  the  reverse  will 
take  place.  It  may  be  expected  that  for  the  general  case, 
control  vectors  are  non-unique  --  that  is,  that  several 
possible  allocations  will  perform  equally  well. 


3.  STATIC  ALLOCATION  ALGORITHMS 


Three  categories  of  static  resource  allocation 
algorithms  have  been  identified  in  this  task.  These  cate¬ 
gories  are  mathematical  programming,  sequential,  and  com¬ 
binatorial.  In  this  chapter,  an  initial  assessment  is 
made  of  the  advantages  and  disadvantages  of  these  kinds  of 
algorithms  in  the  ICNIA  resource  allocation  problem. 


3.1  MATHEMATICAL  PROGRAMMING 

The  mathematical  programming  category  includes  a 
number  of  related  methods.  Among  these  are  linear  pro¬ 
gramming,  integer  programming,  and  a  number  of  nonlinear 
programming  techniques.  All  of  these  methods  are  well 
documented,  and  there  is  a  great  deal  of  available  software 
(Kuester  and  Mize,  1973).  When  these  methods  are  applicable 
to  a  problem,  they  generally  yield  good-quality  solutions. 

Unfortunately,  these  techniques  do  not  appear  to 
be  applicable  to  the  ICNIA  resource  allocation  problem. 
Linear  programming  requires  that  constraints  be  linear  in 
the  control  variables.  In  this  application,  linear  pro¬ 
gramming  would  require  that  the  resource  requirements  in 
each  pool  would  increase  (or  decrease)  steadily  with 
changing  selection  of  the  allocation  control  vector.  Clear¬ 
ly,  this  requirement  is  not  met. 

More  generally,  mathematical  programming  techniques 
require  a  smooth  objective  function  and/or  a  convex  feasible 
region  (Luenberger,  1973).  By  a  smooth  objective  function, 
it  is  meant  that  any  two  control  vectors  that  are  "close" 
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will  yield  objective  function  values  that  are  "close."  By 
"convex  feasible  region,"  it  is  meant  that  any  control 
vector  interpolated  between  two  control  vectors  meeting 
the  constraints  of  Equation  4  will  also  meet  those  con¬ 
straints.  If  either  of  these  assumptions  is  not  met,  these 
methods  will  yield  poor-quality  results,  if  they  can  be 
made  to  work  at  all. 

It  can  be  seen  in  the  example  of  Section  2.3.2 
that  the  static  optimization  problem  does  not  generally 
have  a  convex  feasible  region.  The  control  vectors  (1,  0, 
2)  and  (2,  0,  1)  are  feasible,  but  (1,  0,  1)  and  (2,  0,  2) 
are  not,  indicating  the  nonconvexity  of  the  feasible  region 
In  addition,  this  example  demonstrates  that  the  objective 
function  can  exhibit  significant  discontinuities,  and  is 
thus  unsmooth.  As  a  result,  it  appears  that  standard  mathe 
matical  programming  methods  are  not  applicable  to  the  ICNIA 
resource  allocation  problem. 


3.2  SEQUENTIAL  ALLOCATION 

The  class  of  sequential  allocation  algorithms  is 
intuitively  appealing.  First,  priorities  are  assigned  to 
each  individual  function.  Second,  an  available  resource 
string  is  allocated  to  the  highest  priority  function. 
These  resources  are  not  available  for  subsequent  alloca¬ 
tion  to  functions  with  lower  priority.  Third,  an  avail¬ 
able  resource  string  is  found  for  the  function  with  second 
highest  priority,  and  so  on. 

The  advantages  of  this  algorithm  are  that  it  is 
simple  to  implement  and  fast  to  execute.  The  fast  execu¬ 
tion  speed  is  due  to  the  fact  that  only  a  limited  number 
of  combinations  of  resource  strings  must  be  examined  for 
feasibility,  given  the  current  state  of  system  health. 

However,  the  fact  that  the  algorithm  requires 
priorities  for  each  individual  function  limits  its  flexi¬ 
bility.  As  was  noted  in  Section  2.2.1,  there  are  many 
situations  in  which  such  an  individual  ordering  could  yield 
unacceptable  results. 

In  addition,  the  algorithm  itself  can  result  in 
unnecessary  functional  degradation.  Because  the  algorithm 
does  not  consider  what  resources  will  be  needed  for  a  lower 
priority  function  while  it  is  selecting  a  resource  string 
to  be  allocated  for  a  higher  priority  function,  the  algo¬ 
rithm  may  not  implement  all  functions  even  when  sufficient 
ICNIA  devices  are  available.  An  example  of  this  situation 
will  be  presented  in  Section  3.4. 


3.3 


COMBINATORIAL  METHODS 


In  order  to  avoid  the  difficulties  presented  by 
mathematical  programming  and  sequential  allocation  methods, 
a  new  type  of  allocation  algorithm  was  developed.  These 
are  called  combinatorial  methods. 

In  these  methods,  priorities  are  assigned  to  sets 
of  functions,  as  recommended  in  Chapter  2.  All  possible 
control  vectors  can  then  be  arranged  in  order  of  desirabil¬ 
ity,  according  to  which  set  of  functions  will  be  supported. 
Note  that  there  will  usually  be  several  control  vectors 
which,  if  they  meet  the  constraints  of  Equation  4,  will 
provide  the  same  set  of  functions;  these  are  therefore  of 
equal  desirability.  All  that  remains  is  to  test  each  con¬ 
trol  vector  for  feasibility  given  the  current  state  of 
system  health,  starting  with  the  most  desirable  control 
vector.  The  first  feasible  control  vector  is  selected  for 
implementation . 

For  the  static  case,  this  approach  is  completely 
optimal.  Moreover,  the  algorithm  should  be  reasonably 
simple  to  implement.  The  disadvantage  of  combinatorial 
methods  is  that  the  number  of  possible  control  vectors  is 
likely  to  be  extremely  large.  Although  not  all  control 
vectors  need  to  be  examined  for  each  reallocation,  this 
approach  may  place  an  excessive  burden  on  available  computer 
resources . 

3.3.1  Computational  Trade-Offs 

As  in  almost  all  computer  applications,  it  is 
possible  to  trade  real-time  computational  requirements  for 
memory.  The  most  direct  method  of  implementing  a  combina¬ 
torial  algorithm  is  to  completely  calculate  the  optimal 
control  whenever  a  reallocation  is  required  (due  to  either 
device  failure  or  change  in  priorities).  Although  this 
approach  would  require  little  computer  memory,  a  severe 
processor  load  would  be  imposed.  A  calculation  time  of 
several  minutes  is  possible,  although  the  maximum  calcula¬ 
tion  time  has  not  been  determined. 

At  the  other  extreme,  optimal  controls  could  be 
calculated  off-line  and  stored  in  onboard  memory.  Using 
this  approach,  memory  would  be  required  for  each  possible 
state  of  system  health  and  function  set  priority.  Although 
this  approach  would  result  in  a  negligible  processor  load, 
several  megabytes  might  be  required  for  table  storage. 
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Rather  than  imposing  a  large  peak  processor  load 
or  a  large  memory  requirement,  it  may  be  possible  to  imple¬ 
ment  a  combinatorial  algorithm  using  modest  processor  loads 
and  memory.  The  approach  would  be  to  precompute  and  store 
the  optimal  control  vectors  for  only  the  next  several  pos¬ 
sible  changes  in  system  health  state  and  function  set  pri¬ 
orities.  These  controls  would  be  ready  for  immediate  use. 

Such  an  algorithm  might  reside  in  an  intermediate- 
level  maintenance  facility,  in  a  flightline  computer,  or 
in  an  onboard  computer.  If  the  algorithm  resides  in  a 
maintenance  facility  or  flightline  computer,  a  new  table 
can  be  computed  between  missions  and  downloaded  into  the 

onboard  computer. ^  The  new  table  would  account  for  all 
device  failures  and  maintenance  actions.  If  the  algorithm 
resides  in  the  onboard  computer,  the  new  table  would  be 
computed  as  a  background  task  after  each  reconfiguration. 

Clearly,  the  size  of  the  required  table  increases 
geometrically  with  the  number  of  possible  failures  and 
priority  changes  to  be  anticipated.  The  design  of  a  com¬ 
binatorial  compromise  algorithm  must  balance  required  mem¬ 
ory,  compute  time,  and  the  risk  of  "running  off  the  table" 
after  an  unanticipated  event.  Note  that  a  small,  fast 
backup  algorithm  can  also  be  put  in  place,  if  needed,  to 
avoid  catastrophic  delays. 

The  combinatorial  compromise  offers  the  possibility 
for  fast  reconfiguration  and  moderate  memory  requirements. 

In  addition,  calculation  of  the  optimal  allocation  as  a 
background  task  would  smooth  processor  load.  A  comparison 
of  the  combinatorial  method  with  the  sequential  allocation 
method  for  a  simple  example  is  presented  in  Section  3.4. 


3.4  PERFORMANCE  COMPARISON 

In  this  section,  the  sequential  and  combinatorial 
methods  are  compared  for  the  simple  example  of  Section  2.3.2. 
This  example  involves  three  functions,  to  be  implemented  in 
six  devices.  The  six  devices  are  organized  in  four  pools 
in  two  chains  as  depicted  in  Figure  2. 


Flightline  programming  of  avionics  equipment  is  currently 
performed  in  advanced  Electronic  Countermeasures  ( ECM ) 
systems . 


For  five  ot  the  possible  system  health  states, 
the  selected  allocations  and  supported  functions  for  both 
algorithms  are  presented  in  Table  3.  Note  that  the  sequen 
tial  allocation  algorithm  is  inherently  less  flexible  than 
the  combinatorial  algorithm,  as  it  requires  functions  to 
be  assigned  priorities  individually.  Therefore,  it  cannot 
trade  off  one  function  for  two  slightly  less  important 
functions.  Note  also  that  there  is  one  case  where  the 
sequential  algorithm  cannot  support  all  three  functions, 
even  though  the  combinatorial  algorithm  can.  No  ordering 
of  resource  strings  and  priorities  is  possible  to  avoid 
this  situation;  it  results  from  the  sequential  nature  of 
the  search.  Thus,  it  is  seen  that  the  combinatorial  algo¬ 
rithm  is  both  more  flexible  and  more  efficient  than  the 
sequential  algorithm. 


Tab  Le  3 .  Algorithm  Performance  Comparison 


System  State 


Sequential' 


Combinatorial 

Compromise 


Control 


Functions  ■  Control 


-4- 


Functions 


1, 

2, 

1, 

2 

1, 

2, 

2  1 

Fl, 

F2  , 

F3 

1  i, 

2, 

2 

Fl, 

F2, 

F3 

1 , 

2, 

1, 

1 

1 , 

2, 

0 

FI, 

F2b 

2, 

1, 

1 

Fl  , 

F2, 

F3 

1, 

2, 

o, 

2  ! 

1, 

0, 

0 ! 

F1C 

1  o, 

1 

1  , 

1 

F2, 

F3 

1 , 

1, 

1, 

2  ; 

1 , 

9 

*—  < 

9 

Fl, 

F2  , 

F3  : 

1 

i, 

2  , 

2 

Fl  , 

F2  , 

F3 

0  , 

2  , 

1, 

2  j 

_ 1 

2 

0, 

A 

Fl° 

i 

_ j 

o , 

2  , 

2 

F2, 

F3 

^Priorities:  FI,  F2,  F3 

,Suboptimal  due  to  algorithm  inefficiency 
Sequential  cannot  trade  one  function  for  two  slightly 


less  important  functions 


4  .  ALGOR  I II  iM  EVALUA  i  I  UN 


4.1  PERFORMANCE  MEASURES 

Chapter  2  has  stated  the  optimal  res. mm-  alloca¬ 
tion  problem  and  established  the  framework  in  which  it 
must  be  solved.  There  are  two  general  cat  f^.ade.s  of  nu-asur* 
for  evaluating  the  performance  of  resource  allocation  algo¬ 
rithms;  these  are: 


1.  Measures  of  algorithm  effectiveness: 

They  evaluate  how  nearly  the  algorithm's 
behavior  resembles  that  of  an  optimal 
algorithm. 

2.  Measures  of  computability:  They  evaluate 

the  burden  that  would  be  placed  on  the 
aircraft  computer  systems  it  the  algorithm 
were  implemented. 


In  selecting  a  resource  allocation  algorithm  for 
onboard  allocation,  both  types  of  performance  measures 
must  be  considered.  Clearly,  if  one  algorithm  is  superior 
to  another  in  terms  of  both  effectiveness  and  computability 
that  algorithm  is  to  be  preferred.  If  several  algorithms 
are  evaluated  as  providing  different  mixes  of  effectiveness 
and  computability,  then  trade-off  studies  can  be  performed 
in  order  to  select  the  preferred  algorithm.  Thus,  these 
two  types  of  performance  measures  can  be  valuable  during 
the  system  design  cycle. 

Measures  of  algorithm  effectiveness  are  found  in 
Section  4.1.  Measures  of  computability  are  presented  in 

Section  4.2. 

4.1.1  Measures  of  Algorith m  E  t  f e or i v  e  n  e  s s 

Three  general  algorithm  effectiveness  measures 
have  been  identified  in  this  effort.  They  ore  summarized 
in  Table  4.  All  are  directly  related  to  the  optimization 
problem  discussed  in  Chapter  2.  The  first  of  these  is  the 
Composite  Utility  measure,  which  provides  a  single  figure 
of  merit  representing  the  average  e  f  tee  t  i  vt-ness  of'  tin- 
algorithm  over  a  predetermined  rime  horizon.  the  second 
is  the  Worst  Case  measure.  This  measure  evaluates  t  he 
’irgest  deviation  between  the  functions  supported  by  the 
optimal  algorithm  and  the  functions  supported  !>v  the  ilgo- 
rithm  under  study,  over  a  predetermined  set  ..f  credible 


device  failures.  The  third  measure  of  algorithm  effective¬ 
ness  is  Probability  of  Success.  This  measure  is  closely 
related  to  the  performance  measures  used  in  M1REM  and 
represents  the  probability  that  a  predetermined  set  i.or 
sets)  of  functions  will  be  supported  over  a  predetermined 
t ime  interval . 

All  of  these  measures  are  implicitly  related  to 
possible  maintenance  policies.  If  all  ICNIA  devices  are 
to  be  repaired  after  each  mission,  then  the  time  interval 
of  interest  is  the  mission  duration,  and  the  set  of  cred¬ 
ible  device  failures  should  be  selected  accordingly.  How¬ 
ever,  if  it  is  desirable  to  allow  missions  to  begin  with 
failed  devices,  then  the  time  interval  of  interest  is  the 
maximum  maintenance  interval,  and  the  set  of  credible  device 
failures  is  significantly  larger.  It  is  quite  possible 
that  a  suboptimal  algorithm  which  is  superior  over  short 
periods  will  be  inferior  over  longer  periods.  Algorithm 
effectiveness  measures  are  discussed  in  detail  in  the  fol¬ 
lowing  sections. 


Table  4.  Algorithm  Effectiveness  Measures 


Measure 

— 

Description 

- 

Composite  Utility 

Provides  a  single  figure  of  merit 
representing  the  average  effec¬ 
tiveness  of  the  algorithm  over  a 
predetermined  time  horizon. 

Worst  Case 

Evaluates  the  largest  deviation 
between  the  functions  supported 
by  the  algorithm  under  study 
and  an  optimal  algorithm  over 
a  predetermined  set  of  credible 
device  failures. 

Probability  of 
Success 

_ 

Represents  the  probability  that  a 
predetermined  set  (or  sets)  of 
functions  will  be  supported  over 
a  predetermined  time  interval . 

(This  measure  is  closely  related 
to  MIREM  performance  measures.) 

Composite  Utility.  The  approach  taken  in  this 
performance  measure  is  to  evaluate  the  expected  utility 
attained  using  the  resource  allocation  algorithm  under 
study,  according  to  Equation  2.  This  method  averages  over 
the  probabilities  of  all  device  failures,  and  accounts  for 
the  relative  priority  of  all  sets  of  supported  functions. 
Note  that  the  composite  utility  is  explicitly  a  function 
of  the  time  between  maintenance  actions. 

This  performance  measure  has  several  advantages. 

It  is  derived  directly  from  the  resource  allocation  opti¬ 
mization  problem  so  no  additional  heuristic  inferences  are 
required.  It  results  in  a  single,  comprehensive  figure  of 
merit  so  it  is  easy  to  compare  the  effectiveness  of  several 
different  algorithms  using  this  measure. 

Unfortunately,  the  fact  that  there  is  only  one 
figure  of  merit  means  that  this  performance  measure  does 
not  permit  a  detailed  analysis  of  the  suboptimal  behavior. 

No  indication  is  given  of  what  factors  cause  the  algorithm 
to  work  poorly.  Similarly,  no  indication  is  given  of 
whether  suboptimalities  are  consistent  and  small,  or  occa¬ 
sional  and  large.  These  factors  may  be  significant  in 
selecting  which  suboptimal  algorithm  should  be  implemented. 

Worst  Case.  The  Worst  Case  performance  measure 
is  simply  the  maximum  difference,  over  a  predefined  set  of 
device  failures,  between  the  functional  set  priority  sup¬ 
ported  by  the  optimal  static  algorithm  and  the  functional 
set  priority  supported  by  the  algorithm  under  evaluation. 
This  measure  is  also  directly  related  to  the  optimal  resource 
allocation  problem,  being  defined  from  the  integrand  of 
Equation  2.  In  addition,  this  measure  is  deterministic  -- 
that  is,  it  does  not  depend  on  the  statistics  of  device 
failures . 

The  advantages  and  disadvantages  of  the  Worst 
Case  measure  are  essentially  the  reverse  of  those  of  the 
Composite  Utility  measure.  First,  it  is  straightforward 
to  use  the  Worst  Case  measure  to  analyze  the  conditions  of 
system  health  that  result  in  poor  performance.  Second, 
the  Worst  Case  measure  informs  the  designer  directly  about 
situations  resulting  in  extremely  poor  performance. 

On  the  other  hand,  the  Worst  Case  algorithm  has  a 
number  of  disadvantages.  First,  an  optimal  static  resource 
allocation  algorithm  is  required  for  comparison  (such  as 
the  algorithm  presented  in  Section  3.3).  In  order  to  use 
the  Worst  Case  measure,  an  optimal  reference  algorithm 
must  be  developed  and  run,  which  would  involve  substantial 


costs.  Second,  the  Worst  Case  algorithm  cannot  be  used  to 
assess  the  average  performance  of  the  system;  average  per¬ 
formance  depends  on  the  statistics  of  device  failure. 

Thus,  the  Worst  Case  measure  can  help  in  the  design  of  an 
algorithm  that  avoids  catastrophic  allocation  decisions, 
but  it  cannot  determine  whether  the  algorithm  will  perform 
well  under  average  conditions. 

Probability  of  Success.  The  Probability  of  Success 
performance  measure  is  the  probability  that  a  predefined 
function  set  is  supported  over  the  predefined  period.  This 
can  be  calculated  from  Equation  2  by  assigning  zero  priority 
to  non-relevant  function  sets. 

The  Probability  of  Success  measure  allows  direct 
comparison  with  MIREM.  The  MIREM  measure  is  the  probabil¬ 
ity  of  success  over  a  predefined  period,  given  the  best 
possible  algorithm.  Thus,  comparison  with  MIREM  yields  a 
direct  measure  of  the  effectiveness  of  the  algorithm  under 
test.  If  the  Probability  of  Success  is  computed  for  several 
different  sets  of  functions,  a  detailed  analysis  of  algo¬ 
rithm  suboptimalities  is  possible.  Moreover,  if  the  Proba¬ 
bility  of  Success  is  computed  for  all  sets  of  functions, 
direct  calculation  of  the  Composite  Utility  measure  can  be 
accomplished . 

4.1.2  Computability  Measures 

These  performance  measures  are  designed  to  indicate 
whether  a  proposed  allocation  algorithm  can  be  implemented 
in  available  computer  resources  without  imposing  an  ex¬ 
cessive  burden.  There  are  two  categories  of  computability 
measures:  memory  requirements  and  processor  load. 

Memory  is  required  both  for  program  space  and  for 
data  space.  Program  and  data  may  require  different  types 
of  memory  (for  example,  read-only  memory  versus  random-access 
memory)  and  should  be  calculated  separately. 

Similarly,  processor  load  should  be  assessed  both 
on  the  basis  of  peak  load  and  average  load.  Peak  load  will 
probably  occur  when  a  system  reconfiguration  is  required, 
whereas  average  load  is  relevant  to  allocation  algorithms 
that  perform  background  calculations  (as,  for  example, 
precomputation  of  several  likely  possibilities  for  the 
next  reconfiguration). 

Peak  processor  load  directly  affects  the  reconfig¬ 
uration  delay.  ICNIA  specifications  require  configuration 
delay  to  be  limited  to  a  maximum  of  10  seconds,  including 
failure  detection,  resource  allocation,  and  reinitialization. 
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Some  algorithms  may  require  more  time  for  some  combinations 
of  system  health  state  and  function  set  priorities  than 
for  others.  For  this  reason,  allocation  delay  should  be 
calculated  for  both  the  average  case  and  for  the  maximum. 

The  evaluation  of  these  factors  is  not  a  straight¬ 
forward  numerical  comparison.  Growth  potential  must  also 
be  considered.  Sensitivity  to  such  factors  as  added  func¬ 
tions,  changes  in  resource/function  definitions,  redefini¬ 
tion  of  functional  set  priorities  must  also  be  evaluated 
and  weighed  against  the  ability  of  the  system  to  expand, 
if  necessary,  to  accommodate  the  changes. 


4.2  EVALUATION  METHODS 

A  software  tool  is  needed  to  evaluate  measures  of 
algorithm  effectiveness  for  a  wide  range  of  suboptimal 
algorithms.  Since  many  types  of  algorithms  might  be  pro¬ 
posed,  very  few  statistical  assumptions  can  be  used  to 
simplify  evaluation. 

Any  of  the  performance  measures  proposed  in  Sec¬ 
tion  4.1.1  can  be  evaluated  using  Monte  Carlo  methods. 
These  methods  involve  actually  implementing  the  algorithm 
and  operating  it  over  a  statistically  significant  number 
of  resource  failure  sequences.  Thus,  the  evaluation  soft¬ 
ware  must  include  resources  strings,  statistical  models  of 
resource  failure,  and  the  true  priorities  attached  to  sets 
of  functions,  in  addition  to  the  algorithm  under  evalua¬ 
tion.  Although  there  are  no  significant  theoretical 
difficulties  with  this  approach,  software  development  is 
required,  and  evaluation  run  times  could  be  substantial. 
Furthermore,  true  priorities  have  not  yet  been  established 
by  the  Air  Force. 

Although  it  would  be  desirable  to  evaluate  the 
Probability  of  Success  measure  in  the  same  computational 
framework  used  by  MIREM,  this  may  not  be  possible  due  to 
computational  shortcuts  in  the  MIREM  software.  These  short 
cuts  take  advantage  of  the  fact  that  in  MIREM  only  the 
best  possible  allocation  is  of  interest.  Such  shortcuts 
are  clearly  inapplicable  in  the  context  of  evaluating  the 
performance  of  allocation  algorithms. 


SUMMARY  AND  RECOMMENDATION'S 


5.1  SUMMARY 

The-  ICNIA  system  approach  to  improved  reliability 
and  decreased  logistical  support  requirements  employs  an 
active  redundancy  concept  which  relies  on  a  resource  allo¬ 
cation  process  to  respond  to  changing  mission  requirements 
and  compensate  for  the  loss  of  system  components.  This 
report  establishes  that  the  optimal  solution  to  this  prob¬ 
lem  requires  a  dynamic  stochastic  optimization.  The  opti¬ 
mal  algorithm  would  consider  timing  and  fault  isolation  as 
part  of  a  global  view  of  the  ICNIA  system.  However,  solu¬ 
tions  to  this  overall  optimization  problem  are  very  diffi¬ 
cult  to  compute  and  do  not  appear  to  be  feasible. 

Under  two  simplifying  assumptions,  the  dynamic 
stochastic  optimization  problem  can  be  reduced  to  a 
sequence  of  static  problems  that  can  be  solved  readily. 
First,  the  total  reconfiguration  time  must  be  small  rela¬ 
tive  to  the  allowable  downtime  of  any  function;  second, 
resource  failure  detection  must  be  separated  from  the 
resource  allocation  algorithm.  Any  separate  fault  isola¬ 
tion  process  then  results  in  an  updated  system  health  state 
and  triggers  a  reconfiguration  event. 

Three  performance  measures  which  evaluate  the 
effectiveness  of  the  resource  allocation  algorithms  have 
been  derived  from  the  optimization  framework.  Each  of 
these  performance  measures  explicitly  depends  on  the  time 
between  maintenance  actions,  thus  allowing  the  interaction 
between  the  resource  allocation  algorithm  and  maintenance 
policies  to  be  considered.  Software  using  Monte  Carlo 
statistical  methods  can  be  developed  to  evaluate  the  per¬ 
formance  of  alternative  allocation  algorithms  against  these 
performance  measures.  Of  these  measures .  the  Probability 
of  Success  measure  is  the  most  versatile,  and  its  results 
can  be  compared  directly  with  MIREM  in  the  algorithm  and 
svs tern  des i gn  eye le . 

In  addition  to  algorithm  performance,  a  system 
designer  must  consider  the  ability  to  implement  the  algo¬ 
rithm  within  the  ICNIA  system  constraints.  Implementation 
characterist ics  identified  here  include  memory  require¬ 
ments,  processor  load,  and  total  reconfiguration  time.  In 
addition,  the  margin  of  safety  and  the  sensitivity  of  the 
implementation  to  changes  in  system  constraints  must  be 
cons  1 de red . 


Three  potential  algorithm  design  approaches  were 
evaluated  against  the  basic  criteria  of  effectiveness  and 
computability.  The  firsc  approach,  including  linear  pro¬ 
gramming  and  associated  techniques,  was  found  to  be  inap¬ 
plicable  to  the  ICNIA  problem.  The  second  approach  --  that 
of  sequentially  assigning  functions  on  the  basis  of  indi¬ 
vidual  priorities  --  was  demonstrated  to  result  in  unneces¬ 
sary  functional  degradation  even  for  a  very  simple  example. 
In  addition,  this  approach  is  intrinsically  incapable  of 
allowing  trade-offs  between  sets  of  functions,  as  in  the 
"limp  home"  situation. 

A  third  method,  termed  the  Combinatorial  Method, 
was  proposed.  This  method  would  store  in  memory  the  op¬ 
timal  allocation  for  the  resources  currently  available  and 
for  the  next  several  possible  sequences  of  resource  fail¬ 
ures.  After  each  reallocation  for  resource  failure,  the 
algorithm  would  recompute  the  optimal  allocation  for  the 
next  set  of  resource  failures  as  a  background  processing 
task.  This  approach,  if  feasible,  will  provide  an  optimal 
static  resource  allocation. 


5.2  RECOMMENDATIONS 

Currently,  the  sets  of  functions  required  to  support 
each  mission  phase  have  been  defined.  To  design  or  evaluate 
an  allocation  algorithm,  a  priority  list  by  set  of  functions, 
rather  than  individual  functions,  must  be  established  within 
each  mission  phase.  This  list  will  permit  the  algorithm 
to  delineate  what  subset  of  these  functions  (or  substitute 
functions)  is  the  next  most  desirable,  down  to  a  set  of 
"limp  home"  functions.  Until  this  is  done,  algorithms 
cannot  be  practically  designed  or  consistently  compared  in 
evaluating  performance.  It  is  recommended  that  the  Air 
Force  take  steps  to  establish  such  function  set  priorities. 

It  is  further  recommended  that: 

1.  A  Monte  Carlo-based  model  be  devel¬ 
oped  for  evaluating  the  performance 
of  specific  reconfiguration  algo¬ 
rithms  in  terms  of  Probability  of 
Success . 

2.  The  feasibility  of  using  a  combina¬ 
torial  reconfiguration  algorithm  in 
ICNIA  be  investigated,  and  its  bene¬ 
fits  be  quantified  and  compared  with 
any  other  proposed  algorithms. 
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